11. Compatibility, Features of Future Drive Accelerator

• Accelerates all kind of media e.g.*: Harddisk-, Floppy-, Compact-, ZIP, MagnetOptical- or SyQuest-drives, almost like a RamDrive.
• Uses the free memory as cache , the program reacts automatically on changes in memory resources, so that you will always get the maximum speed for your drives. Even "resources-hungry" programs will get enough memory.
• Minimizes the overall seek time required to read or write data from or to disk. Outstanding I/O requests are ordered such that they can all be performed "with one sweep" of the disk head assembly, from the highest to the lowest disk address (Elevator seeking).
• Gentle, parallel reading and writing in Multitasking.
• Smart-Power-Technologie: Minimizes the number of disk-accesses.
• SmartCache: Read-ahead of blocks.
• When disks are removed, the cache is only removed if necessary. When disks are re-inserted, the cache will be used again.
• No fragmentation of memory. (Opposite to DynamiCache.)
• Can possibly save memory, because dos-buffers are not required anymore.
• Power-LED flashes when accessing cache.
• Verify is as fast as in a copy-program, because data is verified in the background while writing. (the processor isn't used much while writing anyway).
• If DiskSafe is installed, the cache will be written before a reset or system-crash restarts the computer. See section 2. What is required to use Future Drive Accelerator?.
• Supports DiskExpander, Virtual-Memory-Manger (VMM), XFH temporal files and World-Wide-Web browsers.
• Supported devices: (probably all
  • scsi, 2nd.scsi, NewStyleDevice, atapi, cybscsi,
  • trackdisk, floppy, diskspare, hackdisk, mfm.device ((C)CrossDOS), messydisk,
  • fmsdisk,
  • xpkdisk,
  • cd.
• Supported FileSystems: (All knownn)
  • FastFileSystem(FFS), V44.5 V43.20
  • ProfiFileSystem1+2(PFS), HomePage
  • AmiFileSafe(AFS),
  • SmartFileSystem(SFS),
  • MessyFileSystem(MSD),
  • CrossDOSFileSystem(MSD) ((C)CrossDOS),
  • Berkeley (NetBSD LinUX) Fast FileSystem (BFFS UNI\02).
  and compatible, furthermore all MultiUser-"clones".
• Supports FileSystems with a variable block-size.
• Supports harddisks with a capacity of 4 GigaByte or more.
• Protects partitions beyond the 4 GigaByte "barrier" from faulty accesses.
• Is the fastest cache program. Accelerates harddisks by the factor 2-20, floppy disks by the factor 2-997.

11.1 How to use harddisks bigger than 4 GigaBytes.

Type VERSION HD0: into a shell, to find out if version 44.5 or 43.x of the FastFileSystems is installed.

The new FastFileSystem version (9) must be installed into the RigidDiskBlock (RDB) using HDToolBox. Copying to the L: directoy is not enough. (10)

If you have more than one harddisk on your Amiga, the FastFileSystem is loaded only from the Boot-Unit-HardDisk-RDB. So you have to install the new FastFileSystem into the Boot-Unit; but of course doesn't it do any harm if all Unit-HardDisk-RDB's are updated.

Reformatting of the partitionen is not required, this means the files remain accessible with the
new FastFileSystem. The new FastFileSystem works of course with IDE-drives, too.

How do you update the FastFileSystem?
Start the program `SYS:Utilities/HDTools/HDToolsBox':

Select your Boot-HardDisk, `Partition Drive`, `Advanced Options`, `Add/Update...`, now you can see which version is running in your Amiga, `Update File System...`, enter l:FastFileSystem, `OK`, now it should read Version: 44 and Revision: 5, `OK`, `OK`, `OK`, `Save Changes to Drive`, `Exit`.

11.2 DataSafety

The datasafety of the FastFileSystem is extended with Write Async in the case of a power cut.

The ProfiFileSystem-2 and the SmartFileSystem provide datasafety even in the case of a power cut, the medium is always "validated".

The medium is kept "validated" by saving the structure-organizing data to the disk immediatly.
=> You could image this as a tree, whose branches have always to be present, the leaves (files) may grow or fall off without harming the tree itself.
New leaves are written to the "list of existing leaves" when the completely grown up. => Of course, files which were saved during the power cut are lost.

To maintain a valid structure on the medium, the FileSystem must not loose control about the moment of writing, this means the structure must be written "syncron".
=> Write Async may not be activated, to ensure datasafety during a power cut.

Write Async can be activated, if there is enough free memory available to cache the WHOLE write-process.
=> The medium is always "validated".

In future versions, using a new FileSystem, datasafety will be maintained during a power cut, even with low memory, using Write Async. The important structure data (tree) is written "Syncron" and the files (leaves) "Asyncron".

Go to the first, previous, next, last section, table of contents.